<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: Layering</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="layering">
<meta name="uma.presentationName" content="Layering">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_0gpkAMlgEdmt3adZL5Dmdw"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: Layering</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This guideline provides recommendations for partitioning the system into layers.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/tasks/outline_the_arch_FF123A81.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Outline the Architecture</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Software Reuse</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><p>
    Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems.
    Layering logically partitions the system into sets of components with certain rules regarding how relationships can be
    formed between them. Layering provides a way to restrict inter-subsystem dependencies, with the result that the system
    is more loosely coupled and more easily maintained.
</p>
<p>
    Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
    than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
    requirements. Removing layers is not always as easy and may introduce risks into the project.
</p>
<p>
    The criteria for grouping elements into layers follows a few patterns:
</p>
<ul>
    <li>
        <b>Visibility</b><strong>:</strong> Elements may depend only on components in the same layer and the next-lower
        layer.
    </li>
    <li>
        <b>Volatility</b><strong>:</strong> 
        <ul>
            <li>
                <b>In the highest layers</b>, put elements that vary when user requirements change.
            </li>
            <li>
                <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
                language, operating system, database, and so forth).
            </li>
            <li>
                <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
                systems and implementation environments.
            </li>
            <li>
                <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
                model.
            </li>
        </ul>
    </li>
    <li>
        <b>Generality</b><strong>:</strong> Abstract elements tend to be placed in the lower layers. If not
        implementation-specific, they tend to gravitate toward the middle layers.
    </li>
    <li>
        <b>Number of layers.</b> For a small system, three layers are typically sufficient.&nbsp;A three-layer architecture
        of&nbsp;Presentation, Business, and Data layers is very common in information systems.&nbsp; For a complex system,
        five to seven layers could be appropriate. For any degree of complexity, more than 10 layers should be viewed with
        suspicion that increases with the number of layers.
    </li>
</ul>
<p>
    Failure to restrict dependencies according to the visibility criteria mentioned above can cause architectural
    degradation and make the system difficult to extend and maintain.
</p>
<p>
    Allowable exceptions to the visibility rule include cases where components need direct access to lower-layer services
    beyond the next-lower layer. Make a decision about how to handle primitive services that are needed throughout the
    system, such as printing, sending messages, and so forth. There is little value in restricting messages to lower layers
    if the solution is to effectively implement call pass-throughs in the intermediate layers.&nbsp;&nbsp;This usage of a
    less strict rule on dependencies down through the layers is sometimes called a Relaxed Layered Architecture (<a class="elementlinkwithusertext" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html#BUS96" guid="__nHToFndEd2EdJKkAyeBng">[BUS96]</a>).
</p>
<h4>
    <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
</h4>
<p>
    Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
    partitioning present different issues to consider:
</p>
<p>
    <b>User organization</b><strong>:</strong> Elements may be organized along lines that mirror the organization of
    functionality in the business organization (partitioning occurs along departmental or user role lines). This
    partitioning often occurs early in the design&nbsp;due to&nbsp;an existing enterprise model that is strongly
    partitioned according to the structure of the organization. This pattern usually affects only the top few layers of
    application-specific services and can often disappear as the design evolves.
</p>
<ul>
    <li>
        <p>
            Partitioning along user-organization lines can be a good starting point for the model.
        </p>
    </li>
    <li>
        <p>
            The structure of the user organization is not stable over a long period of time because business
            reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
            organization of the system should enable the system to evolve and be maintained independently of the
            organization of the business that it supports.
        </p>
    </li>
</ul>
<p>
    <b>Areas of competence and skills:</b> Elements may be organized to partition responsibilities among different groups
    within the development organization. Typically, this occurs in the middle and lower layers of the system, and reflects
    the need for specialization in skills during the development and support of an infrastructure based on complex
    technology. Examples of such technologies include network and distribution management, database management,
    communication management, and process control, among others. Partitioning along competence lines may also occur in
    upper layers, where special competency in the problem domain is required to understand and support key business
    functionality. Examples include telecommunication call management, securities trading, insurance claims processing, and
    air traffic control, to name a few.
</p>
<p>
    <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
    so to speak, to reflect the distribution of functionality.
</p>
<ul>
    <li>
        <p>
            Partitioning to reflect distribution of functionality can help you visualize the network communication that
            will occur as the system runs.
        </p>
    </li>
    <li>
        <p>
            Partitioning to reflect distribution can also, however, make the system more difficult to change if the
            deployment model changes significantly.
        </p>
    </li>
</ul>
<p>
    <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
    develop or support, require additional partitioning according to security access privileges. Software that controls
    access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
    people with this background on the project is limited, the functionality requiring special clearance must be
    partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
    secrecy areas the only visible aspect of these subsystems.
</p>
<p>
    <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
    the system, should be organized into independent components that are developed and delivered independently from the
    mandatory functionality of the system.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
